ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТ Р исо/мэк 40220—

2015

Информационные технологии W3C SOAP. ВЕРСИЯ 1.2

Часть 2 Дополнения (вторая редакция)

ISO/IEC 40220:2011 Information technology W3C SOAP Version 1.2 Part 2: Adjuncts (Second Edition)

(IDT)

Издание официальное

Москва

Стандартинформ

2015

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного аутентичного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. № 462-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 40220:2011 «Информационные технологии. W3C SOAP. Версия 1.2. Часть 2. Дополнения (вторая редакция)» [ISO/IEC 40220:2011 «Information technology — W3C SOAP Version 1.2 Part 2: Adjuncts (Second Edition)»]

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2015

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

ГОСТ Р ИСО/МЭК 40220—2015

-ДОЛЖЕН генерировать отказ SOAP «env:SendeD> с дополнительным кодом (subcode) enc:MissinglD, если сообщение содержит информационный объект-атрибут ref, но не содержит никакого соответствующего информационного объекта-атрибута id (см. 5.1.5.3);

-    ДОЛЖЕН генерировать отказ SOAP «env:Sender» с дополнительным кодом enc:DuplicatelD, если сообщение содержит два или более информационных объекта-атрибута id с одним и тем же значением (см. 5.1.5.3);

-    МОЖЕТ генерировать отказ SOAP «env:Sender» с дополнительным кодом enc:UntypedValue, если свойство «имя типа» закодированного узла графа не указано.

6 Представление SOAP RPC

Одна из целей протокола SOAP состоит в том, чтобы упростить обмен сообщениями, которые легко отображаются на определения и вызовы методов и процедур в обычных языках программирования. Для этого данный раздел определяет универсальное представление запросов и ответов вызова удаленной процедуры (RPC). Данный раздел не определяет фактические привязки ни к каким определенным языкам программирования. Данное универсальное представление полностью независимо от платформы, и, благодаря значительным усилиям, SOAP стал совместимым с сетью Интернет.

Как упомянуто в разделе 4, использование и реализация представления SOAP RPC НЕ ОБЯЗАТЕЛЬНЫ.

Информационный объект-атрибут SOAP encodingStyle [ИСО/МЭК 40210, пункт 8.1.1] используется для указания стиля кодирования представления RPC. Кодирование, определенное таким образом, ДОЛЖНО поддерживать требования, изложенные в разделе 4. Стиль кодирования, определенный в разделе 5, поддерживает такие конструкции и поэтому подходит для использования в представлении SOAP RPC.

Представление SOAP RPC не основывается ни на каких привязках протокола SOAP. Когда используется привязка SOAP к HTTP, вызов RPC легко отображается на запрос HTTP, и ответ RPC отображается на ответ HTTP (см. раздел 9). Однако, представление SOAP RPC не ограничено привязкой SOAP к HTTP.

Чтобы вызвать RPC, необходима следующая информация:

-    адрес целевого узла SOAP;

-    имя процедуры или имя метода;

-    идентификационные данные и значения любых параметров, которые должны быть переданы процедуре или методу. Параметрам, используемым для идентификации Веб-ресурсов, СЛЕДУЕТ отличаться от параметров, представляющих данные или управляющую информацию (см. 6.1.1);

-значения для свойств, требуемых используемой привязкой. Например, «GET» или «POST» для свойства «http://www.w3.org/2003/05/soap/features/web-method/Method» (см. 8.4);

-    дополнительные данные заголовка.

SOAP RPC использует привязку протокола для обеспечения механизма переноса URI целевого узла SOAP. Для HTTP протокола URI запроса указывает на ресурс, к которому обращен вызов. Кроме требования на правильность URI, SOAP не устанавливает ограничений на форму идентификатора (см. RFC 3986 [RFC 3986] для получения дополнительной информации по URI). В 6.1.1 далее обсуждается использование URI для идентификации ресурсов RPC.

Представление SOAP RPC использует шаблоны обмена сообщениями «запрос-ответ» и «ответ SOAP» (см. 8.2 и 8.3). Представление SOAP RPC МОЖЕТ использоваться с другими шаблонами обмена сообщениями, но это выходит за рамки данной спецификации.

6.1    Использование RPC в сети Интернет

СЛЕДУЕТ руководствоваться нижеизложенными принципами при развертывании приложений SOAP RPC в сети Интернет.

6.1.1    Идентификация ресурсов RPC

В сети Интернет ресурсы идентифицируются с помощью URI, но, согласно общим соглашениям в программировании, идентификационная информация передается процедурам в параметрах или в именах самих процедур. Например, вызов:

updateQuantitylnStock (PartNumber= «123», NewQuantity = «200»)

7

предполагает, что ресурсом, который будет обновлен, является QuantitylnStock для значения параметра PartNumber, равного «123». Соответственно, при сопоставлении с методом или процедурой некоторого языка программирования любые фактические параметры, которые служат для идентификации ресурсов (как номер детали PartNumber в примере выше) должны, когда это целесообразно, быть представлены в URI, к которому адресованы сообщения SOAP Если имя метода или процедуры идентифицирует или уточняет идентификацию ресурса (как QuantitylnStock в примере выше), то при сопоставлении с методом или процедурой некоторого языка программирования такое именование или уточнение должно быть представлено, когда это целесообразно, в URI, к которому адресовано сообщение SOAP Данная спецификация не определяет никаких стандартных средств представления параметров или имен методов.

Примечание — Соглашения для специфического URI-кодирования имен процедур и параметров, а также для управления включением таких параметров в тело SOAP RPC могут быть установлены совместно с разработкой языков описания интерфейсов Веб-службы. Они могут быть разработаны, если SOAP привязан к определенным языкам программирования, или могут быть установлены на базе конкретных приложений или процедур.

6.1.2    Отличие получения ресурсов от других RPC

Всемирная паутина зависит от механизмов, которые оптимизируют часто выполняемые задачи информационного поиска. В частности протоколы, такие как HTTP [RFC 2616], предоставляют метод «GET», который используется для безопасного извлечения информации. Это такое извлечения информации, которое не изменяет данные, не имеет побочных эффектов и которому из соображений безопасности, не запрещено использовать кэшированные результаты или идентификацию, основанную на URI.

Определенные процедуры или вызовы методов представляют собой запросы на получение информации. Например, вызов:

getQuantitylnStock (PartNumber = «123») мог бы использоваться для получения количества, установленного в примере выше.

Следующие соглашения могут использоваться для реализации вызовов SOAP и других вызовов RPC в сети Интернет:

-    соглашения, описанные в 6.1.1, используются для идентификации ресурсов по URI;

-    в случаях, когда все параметры представлены в URI, никакие блоки заголовка SOAP не передаются, и операция извлечения информации является безопасной, используются функция «Веб-метод» (см. 8.4) и шаблон обмена сообщениями «ответ SOAP» (см. 8.3). Соответственно, никакой конверт SOAP не передается для запроса, и значение свойства http://www.w3.org/2003/05/soap/features/web-method/Method устанавливается в значение «GET». Результатом извлечения информации является ответ SOAP RPC, описанный в 6.2.2;

-    в случаях, когда выполняемая операция не является извлечением информации, когда должны быть переданы блоки заголовка SOAP (например, в случае цифровой подписи) или когда извлечение информации не является безопасным, используются функция «Веб-метод» (см. 8.4) и шаблон обмена сообщениями «запрос-ответ» (см. 8.2). Конверт запроса кодируется, как описано в 6.2.1, а результаты извлечения информации описаны в 6.2.2.

Свойство http://www.w3.org/2003/05/soap/features/web-method/Method устанавливается в значение «POST».

Представление SOAP RPC не определяет никаких других значений для http://www.w3.org/2003/05/ soap/features/web-method/Method.

6.2    RPC и элемент Body SOAP

Как RPC вызовы (за исключением безопасных методов извлечения информации, см. 6.1.2), так и ответы содержат элемент SOAP Body [ИСО/МЭК 40210, подраздел 8.3], используемый для представлений, описанных ниже.

6.2.1 Вызов RPC

Вызов RPC моделируется следующим образом:

-    вызов представляется единственной структурой, содержащей исходящее ребро для каждого входящего [in] или входящего/исходящего [in/out] параметра. Структура именуется идентично процедуре или методу. Для представления имен методов, которые не являются допустимыми XML именами, СЛЕДУЕТ использовать соглашения из приложения В;

-    у каждого исходящего ребра есть метка, соответствующая имени параметра. Для представления имен параметров, которые не являются допустимыми XML именами, СЛЕДУЕТ использовать соглашения из приложения В.

ГОСТ Р ИСО/МЭК 40220—2015

Приложения МОГУТ обрабатывать вызовы с недостающими параметрами, но также МОГУТ не обрабатывать такие вызовы и возвращать отказы.

6.2.2    Ответ RPC

Ответ RPC моделируется следующим образом:

-    ответ представляется единственной структурой, содержащей исходящее ребро для возвращаемого значения и по исходящему ребру для каждого исходящего [out] или входящего/исходящего [in/out] параметра. Имя структуры не имеет значения;

-    каждый параметр представляется исходящим ребром с меткой, соответствующей имени параметра. Для представления названий параметров, которые не являются допустимыми XML именами, СЛЕДУЕТ использовать соглашения из приложения В;

-    непустое возвращаемое значение представляется следующим образом:

1    ДОЛЖНО присутствовать исходящее ребро с локальным именем result и именем пространства имен «http://www.w3.org/2003/05/soap-rpc», заканчивающееся в конечном узле;

2    Тип конечного узла — xs:QName и его значение — имя исходящего ребра, которое заканчивается в фактическом возвращаемом значении;

-    если возвращаемое значение процедуры пустое, то исходящее ребро с локальным именем result и именем пространства имен «http://www.w3.org/2003/05/soap-rpc» НЕ ДОЛЖНО присутствовать;

-    отказы вызова обрабатываются согласно правилам, изложенным в 6.4. Если привязка протокола накладывает дополнительные правила для обработки отказа, то они также ДОЛЖНЫ быть выполнены.

6.2.3    Ограничение на кодирование SOAP

При использовании кодирования SOAP (см. раздел 5) в сочетании с соглашением RPC, описанным здесь, элемент Body SOAP ДОЛЖЕН содержать единственный дочерний информационный объект-элемент, который представляет собой сериализованную структуру вызова или ответа RPC.

6.3    RPC и заголовок SOAP

Дополнительная информация, относящаяся к кодированию вызова RPC, но не являющаяся частью формальной сигнатуры процедуры или метода, МОЖЕТ быть представлена в конверте SOAP, переносящем RPC вызов или ответ. Такая дополнительная информация ДОЛЖНА быть представлена в виде блоков заголовка SOAP.

6.4    Отказы RPC

Представление SOAP RPC вводит дополнительные, представленные на внутреннем коде, обозначения отказов SOAP, которые используются в сочетании с кодами отказов (см. [ИСО/МЭК 40210, пункт 8.4.6 «Коды отказа SOAP»]).

Об ошибках, возникающих во время выполнения вызовов RPC, сообщается согласно следующим правилам:

1    Отказ со значением Value элемента Code, равным «env:Receiver», СЛЕДУЕТ генерировать, если получатель временно не может обработать сообщение, например, в случае отсутствия достаточной памяти.

Примечание — Всюду в данном документе термин «значение Value элемента Code» используется как сокращение для «значение дочернего информационного объекта-элемента Value информационного объекта-элемента Code» (см. [ИСО/МЭК 40210, пункт 8.4.1]).

2    Отказ со значением Value элемента Code, равным «env:DataEncoding Unknown», СЛЕДУЕТ генерировать, если параметры закодированы в кодировку, неизвестную получателю.

3    Отказ со значением Value элемента Code, равным «env:Sender», и значением Value элемента Subcode, равным «rpc:ProcedureNotPresent», МОЖЕТ быть сгенерирован, если получатель не поддерживает определенную процедуру или метод.

Примечание — Всюду в данном документе термин «значение Value элемента Subcode» используется как сокращение для «значение дочернего информационного объекта-элемента Value информационного объекта-элемента Subcode» (см. [ИСО/МЭК 40210, подпункт 8.4.1.2]).

4    Отказ со значением Value элемента Code, равным «env:Sender», и значением Value элемента Subcode, равным «rpc:BadArguments», ДОЛЖЕН быть сгенерирован, когда получатель не может произ-

9

вести анализ параметров или когда есть несоответствие в количестве и/или типах параметров между тем, что ожидает получатель и тем, что было отправлено.

5 Другие отказы, возникающие в расширении или в приложениях, СЛЕДУЕТ генерировать как описано в пункте «Коды Отказа SOAP» [ИСО/МЭК 40210, пункт 8.4.1].

Во всех случаях значения информационных объектов-элементов Detail и Reason определяются реализацией. Детали их использования МОГУТ задаваться внешним документом.

Примечание — В ответ на вызов RPC отправители могут получать различные отказы из перечисленных выше, если получатель не поддерживает описанное здесь (необязательное) соглашение RPC.

7 Соглашение для описания функций и привязок

В данном разделе определяется соглашение, описывающее функции (включая шаблоны обмена сообщениями (ШОС)) и привязки в терминах свойств и значений свойств. Соглашения достаточно для описания распределенных состояний спецификаций функций и привязок, как требует спецификация инфраструктуры привязок [ИСО/МЭК 40210, раздел 7]. Оно также используется для описания ШОС «запрос-ответ» (см. 8.2), ШОС «ответ SOAP» (см. 8.3), функции SOAP «Веб-метод» (см. 8.4) и привязки SOAP к HTTP (см. раздел 9) всюду в настоящем стандарте. Помимо самого соглашения, в данном разделе определена неформальная модель, описывающая процесс передачи свойства через систему SOAP. Отметим, что данная модель только иллюстративна и не включает в себя каких-либо ограничений на структуру или иерархическое представление любой конкретной реализации SOAP.

7.1    Модель и свойства

В целом, сообщение SOAP — это информация, которой один узел SOAP хочет обменяться с другим узлом SOAP согласно определенным соглашениям, включая шаблоны обмена сообщениями. Кроме того, может присутствовать информация, важная для обмена сообщениями, но не являющаяся частью самих сообщений. Такую информацию иногда называют метаданными сообщения. В модели сообщения любые метаданные сообщения и различные информационные объекты, определяющие функции, представляются как абстракции, называемые свойствами.

7.1.1    Свойства

В соответствии с соглашением свойства представляются следующим образом:

-    свойства именуются посредством URI;

-    где это уместно, спецификации, вводящей свойство, СЛЕДУЕТ определить тип значения свойства в соответствии со спецификацией XML Schema (см. [XML Schema Part 1], [XML Schema Part 2]).

7.1.2    Область применения свойства

Свойства в узле SOAP различаются по области применения и по источникам их значений. Как показано ниже на рисунке 1, свойства делятся на две группы: свойства для обмена сообщениями и свойства с более широкой областью применения, относящиеся к различным контейнерам. Эти группы называются «контекст обмена сообщениями» и «контекст окружения», соответственно. Все свойства, независимо от областей их применения, совместно используются узлом SOAP и определенной привязкой.

7.1.2.1    Контекст обмена сообщениями

Контекст обмена сообщениями — это набор свойств, область применения которых ограничена экземпляром данного шаблона обмена сообщениями. Пример свойства контекста обмена сообщениями — идентификатор используемого шаблона обмена сообщениями.

7.1.2.2    Контекст окружения

Контекст окружения — это набор свойств, область применения которых выходит за рамки экземпляра данного шаблона обмена сообщениями. Примеры свойств контекста окружения — IP-адрес узла SOAP или текущие дата и время.

Значения свойств в контексте окружения могут зависеть от локальных условий (на рисунке 1 это показано стрелкой, исходящей из контейнера «контекст окружения»), В частности, на свойства в примере может повлиять идентификатор пользователя операционной системы, от имени которого выполняется обмен сообщениями. Отображение информации конкретной реализацией в такие свойства выходит за рамки инфраструктуры привязки, хотя она включает в себя абстрактное представление такой информации как свойства.

ю

ГОСТ Р ИСО/МЭК 40220—2015

8 Шаблоны обмена сообщениями и функции SOAP

8.1 Соглашения о свойствах для шаблонов обмена сообщениями SOAP

В таблице 2 описаны свойства (в соответствии с представленными в настоящем стандарте соглашениями об именовании свойств), на которые опирается описание шаблонов обмена сообщениями (ШОС). Другие свойства могут быть включены в спецификацию конкретных ШОС, но свойства, приведенные в данной таблице, в целом применимы ко всем ШОС.

Таблица 2 — Определения свойств, на которые опирается описание ШОС

8.2 Шаблон обмена сообщениями SOAP «запрос-ответ»

В данном разделе определяется шаблон обмена сообщениями (ШОС) «запрос-ответ». В нем описывается абстрактное представление работы этого ШОС. Данный раздел не предназначен для описания настоящей реализации или для предложений о том, как должна быть структурирована реальная реализация.

8.2.1    Имя функции SOAP

Идентификатор данного шаблона обмена сообщениями: URI [ИСО/МЭК 40210, подраздел 5.6] «http://www.w3.org/2003/05/soap/mep/request-response/».

8.2.2    Описание

ШОС SOAP «запрос-ответ» определяет шаблон для обмена сообщениями SOAP, в котором за сообщением, исполняющим роль запроса, следует сообщение, исполняющее роль ответа. Сообщение-ответ МОЖЕТ содержать конверт SOAP, в противном случае ответ ДОЛЖЕН быть определяемым привязкой сообщением, указывающим, что запрос был получен. При отсутствии отказа нижележащего протокола данный ШОС состоит ровно из двух сообщений.

При нормальном функционировании обмена сообщениями, соответствующими ШОС «запрос-ответ», сообщение-запрос сначала передается от запрашивающего узла SOAP к отвечающему узлу SOAP. После успешной обработки сообщения-запроса отвечающим узлом SOAP сообщение-ответ передается от отвечающего узла SOAP запрашивающему узлу SOAP.

Аварийная работа во время обмена сообщениями «запрос-ответ» может быть вызвана отказом при передаче сообщения запроса, отказом отвечающего узла SOAP на обработку сообщения запроса или отказом при передаче сообщения ответа. Информирование о таких отказах может быть опущено на одном или обоих запрашивающем и отвечающем узлах SOAP, а также может быть осуществлено посредством генерации отказа SOAP или отказа, определяемого привязкой (см. 8.2.4). Кроме того, в случае аварийной работы каждый узел SOAP, участвующий в обмене сообщениями, может по-разному определять успешность выполнения операции обмена сообщениями.

Область применения ШОС «запрос-ответ» ограничена обменом сообщениями запроса и ответа между одним запрашивающим и одним отвечающим узлами SOAP. Данный шаблон не налагает требований ни на корреляции между множественными запросами, ни на определенную синхронизацию множественных запросов. Реализации МОГУТ поддерживать несколько запросов (и связанную с ними обработку ответов) одновременно.

8.2.3    Описание конечного автомата

ШОС «запрос-ответ» определяет ряд свойств, описанных в таблице 3.

Таблица 3 — Определения свойств для ШОС «запрос-ответ»

Чтобы инициировать обмен сообщениями, удовлетворяющий шаблону обмена сообщений «запрос-ответ», отвечающий узел SOAP создает экземпляр локального контекста обмена сообщениями. В таблице 4 описана инициализация контекста.

Таблица 4 — Создание экземпляра контекста обмена сообщениями для запрашивающего узла SOAP

Могут присутствовать и другие свойства, имеющие отношения к операциям экземпляра контекста обмена сообщениями. Такие свойства инициализируются согласно их собственным спецификациям.

После инициализации контекста обмена сообщениями, управление окружением передается (соответствующему спецификации) локальному экземпляру привязки.

На рисунке 2 представлены логические переходы между состояниями запрашивающего и отвечающего узлов SOAP во время обмена сообщениями. В каждом узле SOAP локальные экземпляры привязки обновляют (логически) значение свойства http://www.w3.org/2003/05/soap/bindingFramework/

ExchangeContext/State для отражения текущего состояния процесса обмена сообщениями. Имена состояний — относительные URI, заданные относительно значения базового URI, которое содержится в свойстве http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role локального контекста обмена сообщениями.

Когда локальный экземпляр привязки отвечающего узла SOAP начинает получать входящее сообщение запроса, он логически создает экземпляр окружения обмена сообщениями. В таблице 5 представлены свойства, которые привязка инициализирует при создании экземпляра контекста.

13

ГОСТ Р ИСО/МЭК 40220—2015

Текущее состояние Requesting Запрос Условие перехода: отказ при передаче сообщения. Следующее состояние: «Отказ». Действие: установить http://www.w3.org/2003/05/soap/bindingFramework/ ExchangeContextFailureReason в «transmissionFailure» Requesting Запрос Условие перехода: начато получение сообщения ответа. Следующее состояние: «Отправка и получение». Действие: изменить значение http://www.w3.org/2003/05/soap/rnep/lmmediateSender для обозначения отправителя сообщения ответа (может отличаться от значений в http://www.w3.org/2003/05/soap/mep/lmmediateDestination). Начать конструировать абстрактное сообщение ответа в http://www.w3.org/2003/05/soap/mep/lnboundMessage Sending+ Receiving Отправка и получение Условие перехода: отказ при передаче сообщения. Следующее состояние: «Отказ». Действие: установить значение http://www.w3.org/2003/05/soap/bindingFramework/ ExchangeContext/FailureReason в «exchangeFailure» Условие перехода: завершена отправка сообщения запроса. Завершено получение сообщения ответа. Следующее состояние: «Успех». Действие: если в ответе получен конверт SOAP (т.е. в http://www.w3.org/2003/05/soap/mep/ InboundMessage), то обработать его согласно модели обработки SOAP

Таблица 7 — Переходы для отвечающего узла SOAP

Текущее состояние
Init Инициализация	Условие перехода: начато получение сообщения запроса. Следующее состояние: «Получение». Действие: изменить значение http://www.w3.org/2003/05/soap/mep/lmmediateSender для обозначения отправителя сообщения запроса (если возможно его определить). Начать конструировать абстрактное сообщение запроса http://www.w3.org/2003/05/soap/mep/ InboundMessage. Передать управление контекста обмена сообщениями процессору SOAP
Receiving Получение	Условие перехода: отказ приема сообщения. Следующее состояние: «Отказ». Действие: установить значение переменной http://www.w3.org/2003/05/soap/ bindingFramework/ExchangeContext/FailureReason в «receptionFailure»
	Условие перехода: начало сообщения ответа доступно в http://www.w3.org/2003/05/soap/ mep/OutboundMessage. Следующее состояние: «Получение и отправка». Действие: начать передачу сообщения ответа. Если в абстрактном сообщении в http://www. w3.org/2003/05/soap/mep/OutboundMessage представлен конверт, включить его в сообщение ответа
Receiving + Sending Получение и отправка	Условие перехода: отказ при обмене сообщениями. Следующее состояние: «Отказ». Действие: установить значение переменной http://www.w3.org/2003/05/soap/ bindingFramework/ExchangeContext/FailureReason в «exchangeFailure»
	Условие перехода: завершено получение сообщения запроса. Завершена отправка сообщения ответа. Следующее состояние: «Успех»

Привязка, которая реализует данный ШОС, МОЖЕТ предоставлять потоковую передачу ответов SOAP. Это означает, что отвечающие узлы SOAP МОГУТ начать передачу ответа SOAP в то время, пока запрос SOAP все еще находится в процессе получения и обработки. Если узлы SOAP реализуют привязку, поддерживающую потоковую передачу, применяются следующие правила:

-    ДОЛЖНЫ быть выполнены все правила по 6.2, относящиеся к потоковой передачи индивидуальных сообщений SOAP, и для запросов, и для ответов SOAP;

-    при использовании потоковой передачи привязки SOAP запрашивающие узлы SOAP ДОЛЖНЫ избегать взаимной блокировки при получении и при необходимости обработки информации из ответа SOAP, в то время как передается запрос SOAP.

Примечание — В зависимости от используемой реализации и размера обрабатываемых сообщений, это правило МОЖЕТ потребовать от приложений SOAP, чтобы потоковая обработка ответа уровня приложения происходила параллельно с генерацией запроса;

-запрашивающий узел SOAP МОЖЕТ перейти в состояние «Fail», и таким образом прервать передачу исходящего запроса SOAP, основываясь на информации, содержащейся в ответе SOAP входящего потока.

8.2.4 Обработка отказов

Участвующие в ШОС «запрос-ответ» узлы SOAP во время работы могут генерировать отказы SOAP.

Если отказ SOAP сгенерирован отвечающим узлом SOAP, находящимся в состоянии «Получение», то отказ SOAP помещается в http://www.w3.org/2003/05/soap/mep/OutboundMessage, и конечный автомат переходит в состояние «Получение и отправка».

Данный ШОС не специфицирует порождение или обработку отказов SOAP, сгенерированных запрашивающим узлом SOAP во время обработки сообщения ответа, в состояниях, следующих за состоянием «Успех» в таблице переходов запрашивающего узла SOAP (см. таблицу 6).

8.3 Шаблон обмена сообщениями SOAP «ответ SOAP»

Данный раздел определяет шаблон обмена сообщениями (ШОС) «ответ SOAP». В нем описывается абстрактное представление работы данного ШОС. Данный раздел не предназначен для описания реальной реализации или для предложений, как должна быть структурирована реальная реализация.

8.3.1    Имя функции SOAP

Идентификатор данного шаблона обмена сообщениями: URI [ИСО/МЭК 40210, подраздел 5.6] «http://www.w3.org/2003/05/soap/mep/soap-response/».

8.3.2    Описание

ШОС «ответ SOAP» определяет шаблон обмена сообщениями, в котором за сообщением, которое не является сообщением SOAP, но выступает в роли запроса, следует сообщение SOAP, выступающее в роли ответа. При условии, что нет отказа нижележащего протокола, данный ШОС состоит ровно из двух сообщений, причем только одно из них является сообщением SOAP:

-запрос передается методом, определенным привязкой, который не включает конверт SOAP, и, следовательно, не требует SOAP-обработки получающим узлом SOAP;

-сообщение ответа, которое содержит конверт SOAP. ШОС завершается обработкой конверта SOAP в соответствии с правилами модели обработки SOAP (см. [ИСО/МЭК 40210, раздел 5]).

Аварийная работа во время обмена сообщениями «ответ SOAP» может быть вызвана отказом при передаче сообщения запроса или ответа. Информирование о таких отказах может быть опущено на одном или обоих запрашивающем и отвечающем узлах SOAP или может быть осуществлено с помощью генерации отказа SOAP или отказа, определенного привязкой (см. 8.3.4). Кроме того, во время аварийной работы каждый узел SOAP, участвующий в обмене сообщениями, может по-разному определять успешность выполнения операции обмена сообщениями.

Область применения ШОС «ответ SOAP» ограничивается запросом на сообщение-ответ при обмене сообщениями между одним запрашивающим и одним отвечающим узлами SOAP. Данный шаблон не налагает требований ни на корреляции между множественными запросами, ни на определенную синхронизацию множественных запросов. Реализации МОГУТ поддерживать одновременно несколько запросов и связанную с ними обработку ответов.

Примечание —Данный ШОС не может использоваться в сочетании с функциями, которые задаются в блоках заголовка SOAP в запросе, потому что в данном случае нет конверта SOAP, в который можно было бы их включить.

8.3.3    Описание конечного автомата

ШОС «ответ SOAP» определяет ряд свойств, описанных в таблице 8.

ГОСТ Р ИСО/МЭК 40220—2015

Содержание

1    Область применения ...................................................................................................................................1

2    Нормативные ссылки....................................................................................................................................1

3    Условные обозначения.................................................................................................................................2

4    Модель данных SOAP .................................................................................................................................3

4.1    Ребра графа...........................................................................................................................................3

4.2    Узлы графа............................................................................................................................................3

4.3    Значения................................................................................................................................................3

5    Кодирование SOAP......................................................................................................................................3

5.1    Отображение между XML и моделью данных SOAP.........................................................................4

5.2    Декодирование отказов........................................................................................................................6

6    Представление SOAP RPC..........................................................................................................................7

6.1    Использование RPC в сети Интернет..................................................................................................7

6.2    RPC и элемент Body SOAP .................................................................................................................8

6.3    RPC и заголовок SOAP.........................................................................................................................9

6.4    Отказы RPC...........................................................................................................................................9

7    Соглашение для описания функций и привязок......................................................................................10

7.1    Модель и свойства..............................................................................................................................10

8    Шаблоны обмена сообщениями и функции SOAP..................................................................................11

8.1    Соглашения о свойствах для шаблонов обмена сообщениями SOAP...........................................11

8.2    Шаблон обмена сообщениями SOAP «запрос-ответ».....................................................................12

8.3    Шаблон обмена сообщениями SOAP «ответ SOAP» ......................................................................16

8.4    Функция SOAP «Веб-метод»..............................................................................................................20

8.5    Функция SOAP «Действие»................................................................................................................20

9    Привязка SOAP к HTTP.............................................................................................................................21

9.1    Введение .............................................................................................................................................21

9.2    Имя привязки ......................................................................................................................................22

9.3    Поддерживаемые шаблоны обмена сообщениями .........................................................................22

9.4    Поддерживаемые функции ................................................................................................................22

9.5    Операции шаблонов обмена сообщениями ....................................................................................23

9.6    Соображения безопасности...............................................................................................................27

Приложение А (справочное) Тип медиа    «application/soap+xml» ...............................................................28

Приложение В (справочное) Отображение имен, определенных приложениями, в имена XML..........28

Приложение С (справочное) Использование W3C XML Schema с кодировкой SOAP............................30

Приложение ДА (справочное) Сведения о соответствии ссылочных международных

стандартов национальным стандартам Российской Федерации..................................31

Библиография................................................................................................................................................31

Таблица 8 — Определения свойств для ШОС «ответ SOAP»

Имя свойства Описание свойства Тип свойства http://www.w3.org/2003/05/soap/ mep/OutboundMessage Абстрактная структура, представляющая текущее исходящее сообщение в обмене сообщениями. Данная структура абстрагирует и инфо-набор конверта SOAP (который МОЖЕТ отсутствовать), и любые другие информационные структуры, передающиеся вместе с конвертом Не задан http://www.w3.org/2003/05/soap/ mep/InboundMessage Абстрактная структура, представляющая текущее входящее сообщение в обмене сообщениями. Данная структура абстрагирует и инфо-набор конверта SOAP (который МОЖЕТ отсутствовать), и любые другие информационные структуры, передающиеся вместе с конвертом Не задан http://www.w3.org/2003/05/soap/ mep/lmmediateDestination Идентификатор непосредственного узла назначения исходящего сообщения xs:anyURI http://www.w3.org/2003/05/soap/ mep/lmmediateSender Идентификатор непосредственного отправителя входящего сообщения xs:anyURI

Чтобы инициировать обмен сообщениями, который соответствует ШОС «ответ SOAP», запрашивающий узел SOAP создает экземпляр локального контекста обмена сообщениями. В таблице 9 описано, как инициализируется контекст.

Таблица 9 — Создание экземпляра контекста обмена сообщениями для запрашивающего узла SOAP

Могут присутствовать и другие свойства, имеющие отношения к операциям экземпляра контекста обмена сообщениями. Такие свойства инициализируются согласно их собственным спецификациям.

Как только контекст обмена сообщениями инициализирован, управление контекстом передается к соответствующему локальному экземпляру привязки.

На рисунке 3 представлены логические переходы между состояниями запрашивающего и отвечающего узлов SOAP во время обмена сообщениями. В каждом узле SOAP локальные экземпляры привязки логически обновляют значение свойства http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ State для отражения текущего состояния процесса обмена сообщениями. Имена состояний — относительные URI, заданные относительно значения базового URI, которое содержится в свойстве http://www. w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role локального контекста обмена сообщениями.

17

Введение

SOAP версия 1.2 — это упрощенный протокол, предназначенный для обмена структурированной информацией в децентрализованной, распределенной среде. «W3C SOAP версия 1.2. Часть 2. Дополнения» (данный документ) определяет ряд дополнений, которые МОГУТ использоваться в инфраструктуре обмена сообщениями SOAP.

Данный документ является Рекомендацией W3C, разработанной рабочей группой Протокола XML, которая является частью Действия Веб-служб. Эта вторая обновленная редакция заменяет исходную версию Рекомендации, и в нее включены исправления всех обнаруженных опечаток. Различия между этими версиями описаны в отдельном документе¹). Помимо этого, настоящий документ включает изменения к Шаблону обмена сообщениями «Запрос-ответ» SOAP, разрешающие не использовать конверт SOAP в ответе, для поддержки однонаправленного взаимодействия.

Данный документ рецензировался членами консорциума W3C, разработчиками программного обеспечения, другими группами W3C и заинтересованными сторонами и утвержден директором в качестве Рекомендации W3C. Это устоявшийся документ, на который можно ссылаться и цитировать в других документах в качестве нормативного. Участие W3C в создании Рекомендации должно привлечь внимание к спецификации и способствовать ее широкому применению. Это улучшает функциональность и функциональную совместимость Всемирной паутины.

Отчет о реализациях SOAP 1.2 может быть найден в отдельном документе²).

Дополнительные сведения о реализации шаблона «Запрос с необязательным ответом» можно найти в отчете о тестировании реализаций WSDL 2.0³).

Данный документ соответствует текущей патентной политике W3C СРР⁴) и переходной патентной политике W3C⁵). W3C поддерживает общедоступный список патентов⁶), имеющих отношение к спецификациям, подготовленным рабочей группой. Этот документ, содержащий перечень патентов, также включает инструкции по раскрытию патентов. Если кто-либо обладает действительным знанием патента, который удовлетворяет существенным требованиям, то он должен раскрыть эту информацию в соответствии с разделом 6 патентной политики W3C⁷).

Список текущих Рекомендаций W3C и других технических отчетов можно найти по адресу http://www.w3.org/TR.

^ http://www.w3.org/TR/soap12-part2/diff-part2.html.

²)    http://www.w3.Org/2000/xp/Group/2/03/soap1.2implementation.html.

³)    http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html.

⁴)    http://www.w3.org/TR/2002/NOTE-patent-practice-20020124.

⁵)    http://www.w3.org/2004/02/05-pp-transition.

⁶)    http://www.w3.Org/2000/xp/Group/2/10/16-IPR-statements.html.

^ http://www.w3.Org/Consortium/Patent-Policy-20040205/#sec-Disclosure.

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

W3C SOAP. Версия 1.2 Часть 2 Дополнения (вторая редакция)

Information technology. W3C SOAP. Version 1.2. Part 2. Adjuncts (second edition)

Дата введения — 2016—06—01

1 Область применения

SOAP версии 1.2 (SOAP) является упрощенным протоколом, предназначенным для обмена структурированной информацией в децентрализованной, распределенной среде. Спецификация SOAP состоит из трех частей. Часть 2 (настоящий стандарт) определяет ряд дополнений, которые МОГУТ использоваться в инфраструктуре обмена сообщениями SOAP:

1    Модель данных SOAP представляет определенные приложением структуры данных и значения в виде ориентированного помеченного графа (см. раздел 4).

2    Кодирование SOAP определяет набор правил для кодирования экземпляров данных, соответствующих модели данных SOAP для включения в SOAP-сообщения (см. раздел 5).

3    Представление SOAP RPC определяет соглашение о том, как использовать модель данных SOAP для представления вызовов и ответов RPC (см. раздел 6).

4    Соглашение для описания функций и привязок описывает функции и привязки в терминах свойств и значений свойств (см. раздел 7).

5    Шаблоны обмена сообщениями и функции SOAP определяют шаблон обмена сообщениями «запрос-ответ» и шаблон обмена сообщениями, поддерживающий запросы, не соответствующие протоколу SOAP, для получения ответов по протоколу SOAP (см. раздел 8).

6    Функция SOAP «Веб-метод» определяет функцию для управления методами, используемыми в сети Интернет (см. 8.4).

7    Привязка SOAP к HTTP определяет привязку SOAP к HTTP (см. [RFC 2616]) в соответствии с правилами инфраструктуры привязки SOAP протокола (см. [ИСО/МЭК 40210, раздел 7]).

SOAP 1.2. Часть 0 [SOAP часть 0] не является нормативным документом, предназначенным для использования в качестве простого учебного пособия по функциям спецификаций SOAP версии 1.2.

SOAP 1.2. Часть 1 [ИСО/МЭК 40210] определяет инфраструктуру обмена сообщениями SOAP.

Примечание — В предыдущих версиях данной спецификации название SOAP считалось аббревиатурой. В этой версии это не так.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты и документы. Для датированных документов используют только указанное издание. Для недатированных документов используют самое последнее издание ссылочного документа (с учетом всех его изменений).

ИСО/МЭК 40210:2014 Информационные технологии. W3C SOAP — Версия 1.2. Часть 1. Основы обмена сообщениями (вторая редакция) (ISO/IEC 40210:2014 Information technology. W3C SOAP Version

1.2 Part 1: Messaging Framework (Second Edition))

Издание официальное

Гипертекстовый Протокол передачи — НТТР/1.1 (RFC 2616 Hypertext Transfer Protocol — HTTP/1.1) [RFC 2616]

Ключевые слова, используемые в RFCs, чтобы указать на уровни требования (RFC 2119 Key words for use in RFCs to Indicate Requirement Levels) [RFC 2119]

XML-схема. Часть 1. Структуры. Вторая редакция (XML Schema Part 1: Structures Second Edition) [XML Schema Part 1]

XML-схема. Часть 2. Типы данных. Вторая редакция (XML Schema Part 2: Datatypes Second Edition) [XML Schema Part 2]

Универсальный идентификатор ресурса (URI). Основы синтаксиса (Uniform Resource Identifiers (URI): Generic Syntax) [RFC 3986]

Пространства имен в XML (вторая редакция) (Namespaces in XML (Second Edition)) [Namespaces in XML]

Расширяемый язык разметки (XML) 1.0 (четвертая редакция) (Extensible Markup Language (XML) 1.0 (Fourth Edition)) [XML 1.0]

Информационный набор XML (вторая редакция) (XML Information Set (Second Edition)) [XML InfoSet]

Типы документов XML (XML Media Types) [RFC 3023]

Тип документа «application/soap+xml» (The «application/soap+xml» media type) [RFC 3902]

3 Условные обозначения

Ключевые слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT), «ТРЕБУЕМЫЙ» (REQUIRED), «БУДЕТ» (SHALL), «НЕ БУДЕТ» (SHALL NOT), «СЛЕДУЕТ» (SHOULD), «НЕ СЛЕДУЕТ» (SHOULD NOT), «РЕКОМЕНДУЕМЫЙ» (RECOMMENDED), «МОЖЕТ» (MAY) и «ДОПОЛНИТЕЛЬНЫЙ» (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 (см. [RFC 2119]).

Префиксы пространств имен, использующиеся в данной спецификации, перечислены в таблице 1. Выбор любого префикса пространства имен произволен и не является семантически существенным (см. [XML Info-set]).

Таблица 1 — Префиксы и пространства имен, используемые в данной спецификации

Префикс Пространство имен Примечания епс «http://www.w3.org/2003/05/soap-encoding» Нормативная XML-схема [XML Schema Part 1], документ [XML Schema Part 2] для пространства имен «http://www.w3.org/2003/05/soap-encoding» может быть найден в http://www.w3.org/2003/05/soap-encoding env «http://www.w3.org/2003/05/soap-envelope» Определен в SOAP 1.2. Часть 1 [ИСО/МЭК 40210] грс «http://www.w3.org/2003/05/soap-rpc» Нормативная XML-схема [XML Schema Part 1], документ [XML Schema Part 2] для пространства имен «http://www.w3.org/2003/05/soap-rpc» может быть найден в http://www.w3.org/2003/05/soap-rpc XS «http://www.w3.org/2001/XMLSchema» Определен в спецификации XML-схемы W3C [XML Schema Part 1], [XML Schema Part 2] xsi «http://www.w3.org/2001/XMLSchema-instance» Определен в спецификации XML-схемы W3C [XML Schema Part 1], [XML Schema Part 2]

Имена пространства имен вида «http://example.org/...» и «http://example.com/...» представляют определенные приложением или контекстно-зависимые универсальные идентификаторы ресурсов (URI) (см. [RFC 3986]).

Данная спецификация использует расширенную форму Бэкуса — Наура (РБНФ), определенную в [XML1.0],

Все части настоящей спецификации являются нормативными, за исключением примеров и разделов, отмеченных как «справочное».

2

ГОСТ Р ИСО/МЭК 40220—2015

4    Модель данных SOAP

Модель данных SOAP представляет определенные приложением структуры данных и значения в виде ориентированного помеченного графа. Компоненты этого графа описаны в следующих подразделах.

Модель данных SOAP предназначена обеспечить отображение данных, не основанных на языке XML, в представлении для передачи по каналам данных. Использование модели данных SOAP, соответствующего кодирования SOAP (см. раздел 5) и/или представления SOAP RPC (см. раздел 6) НЕ ОБЯЗАТЕЛЬНО. Приложения, данные которых уже представлены в XML, могут не использовать модель данных SOAP. Так как модель данных SOAP не является обязательной, данная спецификация не требует, чтобы реализация узла SOAP поддерживала модель данных SOAP, кодирование SOAP и/или представление SOAP RPC.

4.1    Ребра графа

Ребро графа исходит из узла графа и заканчивается в узле графа. Ребро, исходящее из узла графа, называется исходящим ребром данного узла графа. Ребро, заканчивающееся в узле графа, называется входящим ребром данного узла графа. Ребро МОЖЕТ исходить и заканчиваться в одном и том же узле графа. У ребра МОЖЕТ быть только начальный узел графа, такое ребро является только исходящим. У ребра МОЖЕТ быть только завершающий узел графа, такое ребро является только входящим.

Исходящие ребра узла графа МОГУТ различаться меткой или позицией. Позиция задает полный порядок таких ребер. Таким образом, если какие-либо исходящие ребра данного узла различаются позицией, то все исходящие ребра этого узла различаются позицией.

4.1.1    Метки ребер

Метка ребра — квалифицированное имя XML. Две метки ребра равны тогда и только тогда, когда полные имена XML равны, то есть когда выполняются оба следующих утверждения:

1    Значения локальных имен совпадают.

2    Выполнено одно или оба из следующих утверждений:

1    У обоих имен отсутствуют значения пространства имен.

2    У обоих имен присутствуют значения пространства имен, и эти значения совпадают.

В 4.3 описано, как метки ребер и позиции ребер используются для различения элементов закодированных значений. Дополнительная информация о сравнении квалифицированных имен XML представлена в стандарте «Схема XML» [XML Schema Part 2].

4.2    Узлы графа

Количество исходящих ребер узла графа может быть больше или равно нулю. У узла графа, не имеющего исходящих ребер, может быть необязательное дополнительное лексическое значение. У всех узлов графа имеется необязательное дополнительное имя типа, представленное значением типа xs.QName из пространства имен «http://www.w3.org/2001/XML Schema» (см. [XML Schema Part 2]).

4.2.1    Одно- и многоссылочные узлы

Узел графа может быть односсылочным и многоссылочным. У односсылочного узла имеется единственное входящее ребро. У многоссылочного узла число входящих ребер более одного.

4.3    Значения

Простое значение представляется как узел графа с лексическим значением.

Составное значение представляется как узел графа с нулевым или большим количеством исходящих ребер следующим образом:

1    Узел графа, исходящие ребра которого отличаются исключительно метками, называется «структура». Исходящие ребра структуры ДОЛЖНЫ быть маркированы различающимися именами (см. 4.1.1).

2    Узел графа, исходящие ребра которого отличаются исключительно позицией, называется «массив». Исходящие ребра массива НЕ ДОЛЖНЫ быть помечены.

5    Кодирование SOAP

Кодирование SOAP обеспечивает средство кодирования экземпляров данных, которые соответствуют модели данных, описанной в разделе 4. Это кодирование МОЖЕТ использоваться для пере-

3

дачи данных в блоках заголовка SOAP и/или теле SOAP. Другие модели данных, альтернативные кодировки модели данных SOAP, незакодированные данные МОГУТ также использоваться в сообщениях SOAP (спецификация альтернативных стилей кодирования описана в «Атрибут SOAP encodingStyle» [ИСО/МЭК 40210, пункт 8.1.1]; ограничения модели данных и кодирования в удаленных вызовах процедур SOAP (SOAP RPC) описаны в разделе 6).

Правила преобразования в последовательную форму, определенные в этом разделе, описаны в документе, идентифицированном URI «http://www.w3.org/2003/05/soap-encoding». Сообщение SOAP, использующее данное конкретное преобразование в последовательную форму, СЛЕДУЕТ обозначать при помощи информационного объекта-атрибута SOAP encodingStyle [ИСО/МЭК 40210, пункт 8.1.1].

5.1    Отображение между XML и моделью данных SOAP

XML допускает очень гибкое кодирование данных. Кодирование SOAP определяет более узкий набор правил для кодирования графов, описанных в разделе 4. Данный раздел определяет кодирование на высоком уровне, а последующие разделы описывают правила кодирования более подробно. Кодировки, описанные в этом разделе, могут использоваться в сочетании с отображением запросов и ответов RPC, определенных в разделе 6.

Кодировки, описанные ниже, представлены с точки зрения десериализатора. В каждом случае предполагается наличие сериализованного XML и описывается его отображение на соответствующий граф.

Обычно для заданного графа возможны несколько вариантов кодирования. При сериализации графа для передачи в сообщении SOAP ДОЛЖНО использоваться представление, десериализация которого порождает тождественный граф; если возможны несколько разных представлений, МОЖЕТ использоваться любое из них. При получении закодированного сообщения SOAP ДОЛЖНЫ приниматься все представления.

5.1.1    Кодирование ребер и узлов графа

Каждое ребро графа кодируется как информационный объект-элемент, и каждый информационный объект-элемент представляет ребро графа. В 5.1.3 описывается отношение между метками ребер и свойствами [local name] и [namespace name] таких информационных объектов-элементов.

Узел графа, в котором завершается ребро, определяется при анализе сериализированного XML следующим образом:

1    Если информационный объект-элемент, представляющий ребро, не имеет среди своих атрибутов информационного объекта-атрибута ref (см. 5.1.5.2), тогда говорят, что информационный объект-элемент представляет узел графа, и ребро заканчивается в этом узле. В таких случаях информационный объект-элемент представляет и ребро графа, и узел графа.

2    Если информационный объект-элемент, представляющий ребро, имеет среди своих атрибутов информационный объект-атрибут ref (см. 5.1.5.2), то значение этого информационного объекта-атрибута ДОЛЖНО быть идентично значению ровно одного информационного объекта-атрибута id (см. 5.1.5.1) в том же конверте. В этом случае ребро заканчивается в узле графа, представленном информационным объектом-элементом, к которому относится информационный объект-атрибут id. Этот информационный объект-элемент ДОЛЖЕН находиться в области действия атрибута encodingStyle со значением «http://www.w3.org/2003/05/soap-encoding» (см. [ИСО/МЭК 40210, пункт 8.1.1]).

Все узлы графа кодируются, как описано выше в случае 1. Дополнительные входящие ребра для многоссылочных узлов графа кодируются, как описано выше в случае 2.

5.1.2    Кодирование простых значений

Лексическое значение узла графа, представляющего простое значение, описывается последовательностью символов Unicode, идентифицированных дочерними элементами информационного объекта-символа информационного объекта-элемента, представляющего данный узел. Информационный объект-элемент, представляющий узел с простым значением, МОЖЕТ содержать информационный объект-атрибут nodeType (см. 5.1.7). Необходимо отметить, что определенные символы Unicode не могут быть представлены в XML [XML 1.0].

5.1.3    Кодирование составных значений

Исходящее ребро узла графа кодируется как дочерний информационный объект-элемент информационного объекта-элемента, представляющего узел (см. 5.1.1). Различные правила применяются в зависимости от того, какой вид составного значения представляет узел графа. Эти правила состоят в следующем:

ГОСТ Р ИСО/МЭК 40220—2015

1    Для ребра графа, которое характеризуется меткой, свойства [local name] и [namespace name] дочернего информационного объекта-элемента вместе определяют значение метки ребра.

2    Для ребра графа, которое характеризуется позицией:

-    порядковая позиция ребра графа соответствует позиции дочернего информационного объекта-элемента относительно его одноуровневых элементов;

-    свойства [local name] и [namespace name] дочернего информационного элемента не являются значимыми.

3    Информационный объект-элемент, представляющий узел с составным значением, среди своих атрибутов МОЖЕТ иметь информационный объект-атрибут nodeType (см. 5.1.7).

4    Следующие правила применяются к кодированию узла графа, который представляет «массив»:

-    информационный объект-элемент, представляющий узел массива, среди своих атрибутов МОЖЕТ иметь информационный объект-атрибут itemType (см. 5.1.4.1);

-    информационный объект-элемент, представляющий узел массива, среди своих атрибутов МОЖЕТ иметь информационный объект-атрибут arraySize (см. 5.1.6).

5    Если ребро графа не завершается в узле графа, тогда оно может быть опущено при сериализации или закодировано как информационный объект-элемент с информационным объектом-атрибутом xsi:nil со значением true.

5.1.4    Вычисление свойства «имя типа»

Свойство «имя типа» узла графа — это пара {namespace name, local name}, вычисляемая следующим образом:

1    Если у информационного объекта-элемента, представляющего узел графа, среди своих атрибутов есть информационный объект-атрибут xsi:type, тогда свойство «имя типа» узла графа — это значение информационного объекта-атрибута xsi:type.

Примечание — Данный атрибут имеет тип xs.QName [Схема XML ч.2]; его значение состоит из пары {namespace name, local name}. Ни префикс, используемый для создания QName, ни любая информация, касающаяся любых определений типа, не являются частью значения. Граф SOAP содержит только полностью квалифицированное имя типа.

2    В случае, если родительский информационный объект-элемент информационного объекта-элемента, представляющий узел графа, среди своих атрибутов имеет информационный объект-атрибут enc:itemType (см. 5.1.4.1), тогда свойство «имя типа» узла графа — это значение информационного объекта-атрибута enc:itemType.

3    В противном случае значение свойства «имя типа» узла графа не определено.

Примечания

1    Эти правила определяют, как свойство «имя типа» узла графа вычисляется из сериализированного кодирования. Данная спецификация не требует проверки корректности с использованием специфического языка для описания схем или системы типов. Также она не включает встроенные типы и не приводит стандартизованных ошибок для описания конфликтов значений и имен типов.

2    Тем не менее, разработка дополнительных спецификаций для описания использования кодирования SOAP, основанного на специфических языках для описания схем или системы типов, не запрещена. Такие дополнительные спецификации МОГУТ накладывать требования на проверку корректности с использованием определенного языка описания схемы и МОГУТ определять, какие должны быть сгенерированы ошибки в случае неуспешно завершившейся проверки корректности. Такие дополнительные спецификации МОГУТ определять дополнения к десериализованному графу на основе информации, полученной после проверки корректности. Использование кодировщиком SOAP атрибута xsi:type предназначено для упрощения интеграции с языком W3C XMLSchema (см. приложение С). Другие языки для описания схем, схемы данных и программных систем типов, основанные на XML, МОГУТ использоваться, но только при условии, что они совместимы с сериализацией, описанной в данной спецификации.

5.1.4.1    Информационный объект-атрибут itemType

Информационный объект-атрибут itemType имеет следующие свойства инфо-набора:

[local name] itemType;

[namespace name] «http://www.w3.org/2003/05/soap-encoding»;

[specified] со значением true.

Тип информационного объекта-атрибута itemType — xs:QName. Значение информационного объекта-атрибута itemType используется для вычисления свойства «имя типа» (см. 5.1.4) элемента массива.

5.1.5    Уникальные идентификаторы

5.1.5.1    Информационный объект-атрибут id

Информационный объект-атрибут id имеет следующие свойства инфо-набора:

5

-    [local name] id;

-    [namespace name] «http://www.w3.org/2003/05/soap-encoding»;

-    [specified] со значением true.

Тип информационного объекта-атрибута id — xs:ID. Значение информационного объекта-атрибута id — уникальный идентификатор, на который можно ссылаться из информационного объекта-атрибута ref (см. 5.1.5.2).

5.1.5.2    Информационный объект-атрибут ref

Информационный объект-атрибут ref имеет следующие свойства инфо-набора:

-    [local name] ref;

-    [namespace name] «http://www.w3.org/2003/05/soap-encoding»;

-    [specified] со значением true.

Тип информационного объекта-атрибута ref — xs:IDREF. Значение информационного объекта-атрибута ref является ссылкой на уникальный идентификатор, определенный информационным объектом-атрибутом id (см. 5.1.5.1).

5.1.5.3    Ограничения на информационные объекты-атрибуты id и ref

Значение информационного объекта-атрибута ref ДОЛЖНО быть идентично значению ровно одного информационного объекта-атрибута id.

Информационный объект-атрибут ref и информационный объект-атрибут id не ДОЛЖНЫ появляться в одном и том же информационном элементе.

5.1.6 Информационный объект-атрибут arraySize

Информационный объект-атрибут arraySize имеет следующие свойства инфо-набора:

-    [local name] arraySize;

-    [namespace name] «http://www.w3.org/2003/05/soap-encoding».

Тип информационного объекта-атрибута arraySize — enc.arraySize. Значение информационного объекта-атрибута arraySize ДОЛЖНО соответствовать следующей грамматике РФБН:

[1]	arraySizeValue	::= («*» | concreteSize) nextConcreteSize
[2]	nextConcreteSize	::= whitespace concreteSize
[3]	concreteSize	::= [0-9] +
[4]	whitespace	::= (#x20 | #x9 | #xD | #xA) +

Атрибут arraySize передает предложенное отображение массива SOAP в многомерную структуру данных программы. Количество элементов списка arraySize представляет число размерностей, а значения — информацию о значениях соответствующих размерностей. Для кодирования SOAP многомерных массивов, узлы выбираются так, чтобы последний подстрочный индекс (т.е. подстрочный индекс, соответствующий последней указанной размерности) менялся чаще всего, а первый — реже всего. Звездочка МОЖЕТ использоваться только на месте первого измерения, чтобы показать, что число элементов в этой размерности не установлено; звездочки не ДОЛЖНЫ появляться в других позициях в списке. Значение по умолчанию информационного объекта-атрибута arraySize — это звездочка «*», т.е. единственное измерение с неуказанным числом элементов.

5.1.7 Информационный объект-атрибут nodeType

Информационный объект-атрибут nodeType имеет следующие свойства инфо-набора:

-    [local name] nodeType;

-    [namespace name] «http://www.w3.org/2003/05/soap-encoding»;

-    [specified] со значением true.

Тип информационного объекта-атрибута nodeType — enc.nodeType.

Если имеется информационный объект-атрибут nodeType, то его значение ДОЛЖНО быть одной из строк: «simple», «struct» или «array». Значение атрибута указывает на тип значения, которое представляет узел: простое значение, значение составной структуры или значение составного массива соответственно.

5.2 Декодирование отказов

Во время десериализации получатель SOAP:

6